feat(components): Allow Configuration of AnimatedPresence#2898
feat(components): Allow Configuration of AnimatedPresence#2898
Conversation
Deploying atlantis with
|
| Latest commit: |
a092313
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://78e85784.atlantis.pages.dev |
| Branch Preview URL: | https://job-150838-animatedpresence.atlantis.pages.dev |
|
Published Pre-release for a9a05ad with versions: To install the new version(s) for Web run: |
| /** | ||
| * The timing of the animation. | ||
| */ | ||
| readonly timing?: Timing; |
There was a problem hiding this comment.
not 100% on this interface
you'll be passing values like "timing-slow" rather than just "slow"
buut it is derived from the tokens which is nice. the only time it might become a hindrance is if we change the token values, the props would need to get fixed in the invocations.
|
|
||
| export type AnimatedPresenceTransitions = keyof typeof transitions; | ||
|
|
||
| type ExitBehavior = "overlap" | "replace" | "sequential"; |
There was a problem hiding this comment.
let me know if these are good, clear names.
I had a couple other ideas to describe "overlap" (crossfade)
and "immediate" instead of "replace"
the actual framer motion values they map to are:
- "overlap" -> "sync"
- "replace" -> "popLayout"
- "sequential" -> "wait"
and here's their descriptions
/**
* Determines how to handle entering and exiting elements.
*
* - `"sync"`: Default. Elements animate in and out as soon as they're added/removed.
* - `"popLayout"`: Exiting elements are "popped" from the page layout, allowing sibling
* elements to immediately occupy their new layouts.
* - `"wait"`: Only renders one component at a time. Wait for the exiting component to animate out
* before animating the next component in.
*
* @public
*/
mode?: "sync" | "popLayout" | "wait";
|
while I could see these changes being useful in general, they don't actually solve the problem that spawned this request. ultimately it's a layout issue that happens to have an animation on it. trying to fit AnimatedPresence into the equation only makes things harder because it truly does conditionally render in order for the animation to apply, however that makes determining/setting the minHeight really tricky where you have to start using 
OR you can just let CSS grid layouts figure out all that for you, and implement a small CSS animation yourself which is what I ended up doing in the problematic scenario. I don't really want AnimatedPresence to have to worry about those layout concerns, nor is it well equipped to handle them in the first place. |
|
see above |
1 participant
Motivations
currently AnimatedPresence (and AnimatedSwitcher) have a static timing, and don't allow you to choose the
modethat is used for enter/exit.the "popLayout" mode can cause issues with some layouts where the animated content is the last thing in the document, causing it to visually shift heights as the exiting element is immediately removed and for a fraction of a second, the other content isn't yet there. so, by allowing choice of exit/enter behavior, this can be tailored to the situation.
as for the timing, we have timing tokens. it seems odd that we would not allow other valid, consistent timing values to be used.
the callback is there so that a consumer can deal with some possible layout quirks such as the one we encountered. it may not solve this case, but I think it's a useful prop to have regardless.
Changes
Added
timingpropexitBehaviorproponExitCompletepropI've intentionally tried to name the
exitBehaviorprop values with more "what"-style names. I do not want us to be tied to framer-motions API, and struggle to figure out what an equivalent is later down the road if we should swap the underlying library. using terms like "sequential" makes it clear to both a consumer and us what is desired VS "wait" which is the library's terminology.Changed
Deprecated
Removed
Fixed
Security
Testing
try the various timing tokens, seee that they do what you expect.
try the new callback, see that it fires when you expect
for the exitBehavior I've added a webstory to demonstrate the difference between the exitBehavior prop value. to see the exact issue, what you'll need is pretty specific:
once we have that, the scenario is that you scroll down and start initiating the animations that swap. using "replace" is the current issue, so you can try that. "sequential" from some testing had the same issue though.
the reason being that the content gets shorter for a frame or two, and we're scrolled to a place that doesn't exist so the scroll/position moves for a moment.
aside from that, just try out the different exitBehavior prop values to make sure they look and feel good! keep in mind they can be combined with all the various
transitionvalues!Changes can be
tested via Pre-release
In Atlantis we use Github's built in pull request reviews.